1. Field of the Invention
The present invention relates to communication networks and, more particularly, to a method and apparatus for detecting a fault on an optical fiber.
2. Description of the Related Art
Communication networks may include various routers, switches, bridges, hubs, and other network devices coupled to and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the communication network by passing logical associations of bits/bytes of data in the form of packets between the network elements over one or more communication links between the devices.
When optical fibers are used to provide communication links between two devices, they are usually deployed in pairs, with each fiber in the pair providing a unidirectional path between the two devices. The optical fibers are connected to the network elements at communication ports, such that an optical transmitter of one port is connected to an optical receiver of another port and vice versa. Since fibers are generally used for unidirectional communication, when a fiber fails or when a far end receiver fails, the transmitting device will not naturally know that the data it is transmitting is not reaching its peer receiver. Accordingly, remote fault indication mechanisms have been developed to enable the network element on the opposite end of the optical fiber to notify the transmitting network element via a second optical fiber that there is a fault on the other fiber.
FIG. 1 illustrates an example two fiber bidirectional communication link 10 that may be used in a communication network. As shown in FIG. 1, the communication link includes ports 12a, 12b on either ends of two or more fibers 14. In this example, each fiber carries data in one direction, either from port 12a to port 12b, or from port 12b to port 12a. Transmit interfaces 16a, 16b are used to transmit data onto the fibers at port 12a and 12b, respectively. Receive interfaces 18b, 18a are used to receive data from the fibers 14a, 14b, respectively. Data to be transmitted over the ports 12a, 12b, is received from switch fabrics 20a, 20b, associated with the network elements hosting the ports. In the absence of any data to be transmitted, the transmit interfaces 16a, 16b will still typically output light at a relatively constant level. When data is present to be transmitted, the output light will be modulated to enable the receive interface to extract the data from the optical signal on the optical fiber 14.
FIG. 1 shows the normal condition with both ports 12a, 12b operating and both fibers 14a, 14b intact. FIG. 2 shows an example of a failure in which a fiber break on one of the fibers 14a prevents data from being transmitted from transmit interface 16a to receive interface 18b. Although FIG. 2 shows a fault on the fiber 14a, other faults such as a fault in the transmit interface 16a or a fault in the receive interface 18b may occur as well and would, in practice, be indistinguishable from a fault on the fiber 14a. As shown in FIG. 2, the network element associated with the port 12a may not be aware of the fault on the fiber 14a, and thus continue to transmit data over the port 12a. To enable this fault to be communicated back to port 12a, port 12b or the network element associated with the port 12b will need to sense the fault on the fiber, shut down the receiver 18b, and then communicate the fault over the remaining available fiber 14b so that port 12a is able to cease transmission of data on transmit interface 16a. 
Generally, link failure detection is performed in hardware using Far End Fault Indication (FEFI) or Remote Fault Indication (RFI), both of which are industry standards for detecting link failure using pre-configured hardware circuits. Where hardware detection of a failure is not available or is cost prohibitive to implement, a software method may be used.
There are currently two ways in which software has been implemented in optical networking equipment to detect a failure on a link. In both of these methods, when a port, such as port 12b, detects a failure on a fiber, it will turn its transmit laser off and on at a specified frequency and duty cycle. Specifically, the port that detects a failure will oscillate power to its transmit laser off and on so that the transmit laser periodically stops sending light over the fiber. The frequency and duty cycle of the transmit laser oscillations may be, for example, one oscillation every 12 seconds with the signal being off for 4 seconds and on for 8 seconds, as shown in FIG. 3.
The difference between the two ways of using software to detect a failure on a link is in how the receiver 18a interprets a loss of signal on the fiber 14b. In either instance, a loss of signal on the receive interface 18a will cause the port 12a to determine that the receive interface 18a is down. However, since the loss of signal may be an isolated loss of signal or a periodically generated loss of signal intentionally being generated by the far end port 20b as an attempt to signal a failure on the fiber 14a, the loss of signal is monitored by the port so that it can determine how to operate its transmit interface.
In one method (immediate mode), a loss of signal on the receive interface 18a is immediately assumed to be intentionally generated as part of the oscillating off/on pattern associated with a failure on fiber 14a, so that the transmit interface 16a is immediately shut down upon detection of a loss of signal on fiber 14b. Using this method allows the transmit interface 16a to be shut down quickly in the event of a failure on fiber 14a so that minimal data will be lost should a failure occur on that fiber. However, this mode of operation also causes the transmit interface to be shut down any time a fiber is disconnected for a short period of time, which may occur for maintenance such as re-routing of cables and for other common reasons. For example, if fiber 14b were to be disconnected in FIG. 1, use of immediate mode would cause the other fiber in the fiber pair 14a to be shut down by causing transmit interface 16a to cease transmission. Additionally, the transmit interface 16a may be required to be shut down for a full cycle to enable the port 12a to determine whether the loss of signal at receive interface 18a was part of an isolated incident or was part of an intentionally generated off/on oscillation pattern intended to signal a fault on fiber 14a. 
In another method (multiple cycle detection mode), a loss of signal on the receive interface 18a is not assumed to be part of the off/on pattern associated with a failure on fiber 14a until five off/on cycles have been received. This method enables a fiber to be disconnected for a short period of time without causing the port 12a to unnecessarily disable the peer fiber by shutting down the transmit interface 16a. However, since it takes five cycles to recognize the offon pattern as indicating a fault on fiber 14a, a significant amount of data may be lost while the port is waiting to determine if there is a fault on the fiber.
Conventionally, if a network element included the ability to detect a fault on a fiber using software, the network element would be configured to implement only one of these methods. Specifically, depending on the particular network element, the network element would be programmed to use either the multiple cycle detection mode or the immediate mode. Accordingly, it would be advantageous to provide a way to choose an immediate mode or multiple detection mode, or in general, any intermediate setting to detect a fault on a communication link.